Atari Mega Archive 1/Atari Mega Archive - Volume 1.iso/lists/gem/l_0799/424

Internet Message Format | 1994-08-27 | 7.6 KB

From: [e-mail]
Date: Sun, 12 Jun 94 19:43:00 UTC
To: [e-mail]
Subject: Indigestion
X-Genie-Id: 3657565
X-Genie-From: DMJ
Precedence: bulk

Evan,

 - On the subject of cookie jars, another problem with this is
 - that it requires super-visor mode.

This is not a problem.  It takes just about _zero_ time to read the
cookie jar, which I doubt would make a significant impact, even on
MiNT.

 - If GFA Basic is incapable of doing something as simple as
 - reading an address from fixed place in memory, then too damn bad.

Actually, reading the address of the cookie jar is as simple as this:

 jar%=LPEEK(&H5A0)

GFA automatically drops into supervisor mode to read the memory
address.  I've found GFA in many ways is easier to use for poking
around in memory, because it requires less "busywork" by the
programmer to do what they want.  (This doesn't mean GFA is good for
everything, though, and I dislike some of the same things about it as
you.)

 - Anyway, there is a solution to both problems.  Provide a GEMDOS
 - call to manipulate the cookie jar.

Why not use JARxxx, which is Freeware, which provides XBIOS functions
for doing this?  This was put together by Dan Wilga @ Gribnif
Software, specifically to address the problems of using the cookie
jar.  I plan on using JARxxx with my own software, so I'm not
advocating anything I'm not prepared to do myself.

 - I really don't like cookie jar stuff.

Not everybody shares your bias.  Also, the "accepted" method of doing
this sort of thing is to make the cookie's value a pointer to a
structure in RAM--this is enormously convenient.

Ofir,

 - I'm against an ASCII file for the user to edit. Parsing is a
 - pain and users are likely to hate it anyway. Someone will have
 - to create an editor.

Fine.  You might also consider using a small AUTO program to load the
shortcut file into RAM, so that programs don't have to go looking for
a disk file just to read the user-selected keyboard shortcuts.  I
can't imagine this file (which is non-ASCII) being all that large, so
it won't take very much RAM.  Also, this would make things a lot more
bearable for those (few) users who don't have a hard drive.

An editor would, of course, modify both the copy in memory and the
copy on disk.

 - Because most users will not bother changing the keyboard.cnf
 - (or whatever it's called).

Would it *really* be much trouble to have default KEYBOARD.CNF files
for different languages, and just use the most appropriate one?

 - Why does CTRL+W mean Close Window? It's not that obvious.

It's a lot more obvious than CTRL-U--at least "w" bears some relation
to "Window", but "u" doesn't even come close.

 - The majority of programs I get to review in the UK use CTRL+U
 - to close a window.

The majority of programs I actually _use_ don't have any consistency
at all.  What I spend most of my _time_ in, though, uses CTRL-W.

 - The German developers had the sense to come up with their own
 - standard long before we did. Give them credit and try to cooperate.

My point is that they developed keyboard shortcuts which make perfect
sense to them, but are absolutely baffling to those of us who don't
speak German.  I find it pretty amazing that you want to "marry" two
standards that are based on some very different assumptions; at least
two "standards" are needed, but that seems like a non-standard
standard.

What I'd rather see is a method whereby programs can retrieve a set of
"global" keyboard shortcuts, but in the absence of such a set, can use
whatever the programmer feels is "best" for that particular
application.  (The application developer, not you or anybody else, is
in the best position to decide what is best for their programs.) That
way anybody who cares enough about their keyboard shortcuts can have a
set defined, which programs will use; anyone who doesn't can use
whatever the programmer feels like.  If a key definition file is
present, it would *totally* and *transparently* replace whatever
keyboard shortcuts the programmer had selected.

Here's an example, food for thought.  What if you're working with an
application which is *not* primarily text-oriented?  This leaves
unshifted letter keys suddenly available for keyboard shortcuts; this
makes everything _much_ simpler.  But with your standard, I would need
to have all the CTRL- and CTRL-SHIFT- keys, because that's what every
other application (which, from the nature of the discussion here,
seems to be almost exclusively text-based applications) is using.  For
an application that is not text-based, the user's right hand is
normally on the mouse, with the left hand on the keyboard; making
shortcuts that can be accessed with _one_hand_ suddenly becomes very
important, and not having to use CTRL or SHIFT makes that a lot
easier.

 - Seriously though, the majority of software now originates in
 - Germany...

Then why are you bothering with us English-speakers?  What I'm trying
to say is that if you have a single standard which has some things
difficult for English-speakers to remember, and some things difficult
for German-speakers to remember, you'll be annoying _both_ groups.
Come up with separate recommendations.  If they're dynamically
configurable, it doesn't matter if there is more than one set.

 - The easiest way to remember shortcuts is when all programs use
 - the same ones.

No, the easiest way to remember shortcuts is when they are _used_.
The example you cite (CTRL-X/C/V) is useful because you can hit it
with one hand.  Most of the time, if I have to use two hands for a
keyboard shortcut, I don't use it.  A shortcut that isn't much of a
shortcut won't get used.  This is one more reason I prefer CTRL-W over
CTRL-U; CTRL-W I can easily hit with one hand.  Most of the time, my
right hand is on the mouse, and my left hand is on the keyboard.  If
have to move my right hand off the mouse and onto the keyboard to hit
a shortcut key, it isn't a shortcut!

 - Programs that will not follow the standard (if and when it is
 - widely accepted) will get bad scores on "Ease of Use" in magazines
 - and users will complain.

"If and when" being the operative word.  Without support from
programmers, it won't be widely accepted--and I will not follow a
standard which I think doesn't make sense.

Bo,

 - How difficult would it to be in applications to implement a kind
 - of shortcut key "double-click"?

Two comments.  First, when it comes to mouse operations, there are two
operations that are the hardest and/or the most tiring to do; these
are the double-click and the click-drag.  Depending on your physical
condition (and mousing skills), these may be anywhere from slightly
annoying to painful.  I think it reasonable to assume a key
double-click is not all that easy for the user to perform, especially
on an _Atari_ keyboard.

Second, how do you distinguish between a key double-click and a key
repeat?

 - ...there is also a tendency to lose sight of the proposal's
 - concept that we are here dealing with _minimum_ system-wide
 - application _defaults_, not a rigid Apple-like "always do it
 - this way or we will not endorse your application".

Hear, hear!  Please, no heavy-handed domination by the "standard";
make it a "recommendation" instead.

Annius,

 - A good extra note in the guidelines would be that if ever a
 - programmer decides to use a keycode from the proposal for
 - something DIFFERENT, s/he should watch out that it is not
 - dangerous when a user assumes the standard meaning (as set out
 - in the proposal) and simply hits the key without RTMF.

Good point.  Any standard which includes recommendations for what to
do when you must deviate from it is more foresighted than most.

 -+- Damien M. Jones -+- dmj software -+- [e-mail] -+-